A privilege-escalation vulnerability Microsoft’s Azure Functions cloud container feature could ultimately allow a user to escape the container, according to researchers.
Intezer researchers dubbed the bug “Royal Flush” after a flush-to-disk limitation that an exploit would need to evade. Flushing to disk means that data is handed off to the kernel, where it’s visible to other processes but may not survive a reboot.
The firm found that Azure Functions containers run with the –privileged Docker flag, which means that device files in the /dev directory can be shared between the Docker host and the container guest. The vulnerability stems from the fact that these device files have read-write permissions for “others.”
“The lax permissions on the device files are not standard behavior,” according to the analysis, released on Thursday.
The issue becomes a problem given that the Azure Functions environment contains 52 different partitions with file systems, which can be visible across users, according to Intezer.
“We suspected that these partitions belonged to other Azure Functions clients, but further assessment showed that these partitions were just ordinary file systems used by the same operating system, including pmem0, which is the Docker host’s file system,” researchers explained.
“This could become dangerous in the case where the attackers have access to the victims’ environment, as a low-privileges user,” Ari Eitan, vice president of research at Intezer, told Theatpost. “Using this vulnerability, an attacker can escalate privileges and do things he should not do (read files from the file system, for example).”
Further, while the bug is not a direct Docker escape vulnerability, “if a user is able to escalate to root, they would be able to escape to the Docker host using various Docker escape techniques,” he said. “Merging those two together is a great power for attackers.”
Royal Flush Cloud-Container Exploit
To probe for attack paths that could arise from this setup, the researchers created a local test container. They found that using the Debugfs utility (a special utility used for debugging the Linux kernel, which can be used to examine and change the state of a file system), an unprivileged user can easily traverse the Azure Functions file system. And, it turns out that an unprivileged user can also directly edit any files found within.
“At first, we tried to edit the file’s contents using the zap_block command by directly editing file system blocks’ contents,” according to the analysis. “Internally, the Linux kernel treats these changes to the *device file* /dev/sda5, and they are write-cached in a different location than changes to the *regular file* /etc/passwd. As a result, it is required to flush changes to disk, but this flush is handled by the Debugfs utility.”
However, researchers were able to find a way around this limitation on making direct changes to files.
“First, we created a hard link via Debugfs into our container’s diff directory so that changes would radiate to our container,” researchers explained. The diff directory is a full enumeration of the objects within the container.
They added, “This hard link still requires root permissions to edit, so we still had to use zap_block to edit its content. We then used posix_fadvise to instruct the kernel to discard pages from the read cache (flush them, hence the name of the technique), inspired by a project named ‘pagecache management.’ This caused the kernel to load our changes and we were finally able to propagate them to the Docker host file system.”
Debugfs also supports a write-mode, allowing users to make changes to the underlying disk, noted researchers: “It’s important to note that writing to a mounted disk is generally a bad idea as it can cause corruption in the disk,” they added.
With the ability to edit arbitrary files belonging to the Docker host, an attacker can make changes to the /etc/ld.so.preload file, researchers explained – which would allow a “preload-hijack” attack that spreads a malicious shared object through the container’s diff directory.
“This file could be preloaded into every process in the Docker host system (we previously documented HiddenWasp malware using this technique) and thus the attacker would be able to execute malicious code on the Docker host,” according to the analysis.
Intezer reported the vulnerability to Microsoft Security Response Center (MSRC), but no patch will be forthcoming. The computing giant determined that the vulnerability “has no security impact on Azure Functions users,” according to the analysis, because the Docker host used by the researchers was actually a HyperV guest and thus protected with another sandboxing layer. That’s not to say though that the weakness couldn’t be dangerous in a different configuration.
“Despite the fact that MSRC says there’s nothing to worry about, we believe that an advanced attacker could take advantage of this vulnerability and that it could help him as part of an attack,” Eitan said. “This is why we published it.”
The researchers provided proof-of-concept exploit code as well:
Microsoft did not immediately return a request for comment.
“Cases like this underscore that vulnerabilities are sometimes unknown or out of the cloud consumer’s control,” Intezer recommended. “A two-pronged approach to cloud security is recommended: Do the basics, like fixing known vulnerabilities and hardening your systems to decrease the likelihood of getting attacked, as well as implementing runtime protection to detect and respond to post-vulnerability exploitation and other in-memory attacks as they occur.”
Ever wonder what goes on in underground cybercrime forums? Find out on April 21 at 2 p.m. ET during a FREE Threatpost event, “Underground Markets: A Tour of the Dark Economy.” Experts will take you on a guided tour of the Dark Web, including what’s for sale, how much it costs, how hackers work together and the latest tools available for hackers. Register here for the Wed., April 21 LIVE event.
